Reflection is a powerful mechanism provided by some major object oriented languages and frameworks that allows to access information about classes and their members at metadata level, and use it in different scenarios. Some of few use cases are: detecting what kind of methods or fields does the class have, detecting the specific field data type at runtime, dynamically invoking method which name is unknown at compile time. These are non-standard cases of classical object oriented programming, but they make a great significance in contemporary object oriented design solutions and frameworks where modularity and extensibility are key values (1).
Reflection is designed the way that metadata access is not straightforward and type-safe for distinct members. The usual scenarios of using reflection allow:                traversing class fields or members, and doing the processing operations on each iteration;        checking if a specific member (field, method, constructor, event, property . . . ) with a specified name (and possible additional signature information for the latter) exists, and then processing it.This approach does not allow direct and type-safe access of distinct fields or methods which programmer is aware of (2), (3), (4), (5).        
FIG. 1 demonstrates C# example class named ‘Person’ declaration which has instance level field named ‘FullName’ and static field ‘TotalPersons’. FIG. 2 demonstrated: getting metadata information about these fields.
FIG. 3 and FIG. 4 demonstrate same example in programming language JAVA®. JAVA® also allows accessing both private and public fields. In case of JAVA® there's a special case of retrieving class metadata by using “class” keyword as a member of class. Please note that JAVA® has some differences in metadata retrieval and metadata structure (e.g., Constructor has a single generic parameter referencing to a constructor holder class), but conceptual approach is almost identical to that of C#.
Previously demonstrated examples show existing technique of accessing metadata in two major general purpose programming languages: C# and JAVA®. Providing type member name as string instances to access type member metadata are not type safe. It means that code is not reliable for maintenance (refactoring) and also if there is a mistake it will be noticed only at runtime.
The most obvious benefit of static type-checking is that it allows early detection of some programming errors. Errors that are detected early can be fixed immediately, rather than lurking in the code to be discovered much later, when the programmer is in the middle of something else or even after the program has been deployed. Most of general purpose object-oriented programming languages are strongly typed, but none of them provide fully type safe metadata access mechanism—they lack type safe type (class/structure) member metadata access. Not all programming languages support metadata access mechanisms like reflection, but for languages which support metadata access, type safety in this field is considered to be a property of a computer program rather than the language in which that program is written. In such cases programmer is responsible for type safety which means correct metadata representation in basic data types, usually strings.
FIG. 5 demonstrates member metadata access use case in MVVM design pattern usage (6). Best that programmer can do if programming language does not have strongly typed type member metadata access is checking type member names (metadata) at runtime which only partly solves type safety issues, but on downside makes code more complex, forces programmer to use redundant type expressions and leads to performance slowdown. Microsoft® provides best practices to access metadata in mentioned type safe way using lambda expressions (7), (8). Metadata access example using lambda expressions are shown in FIG. 6. Unfortunately described practices do not guarantee 100% type safety and desired result. In case if programmer provides lambda expression which does not contain member access expression, program execution will fail.
In C#5, it is possible to tag optional parameters with one of three caller info attributes (9), (10): [CallerMemberName] applies the caller's member name; [CallerFilePath] applies the path to caller's source code file; [CallerLineNumber] applies the line number in caller's source code file. By using CallerInfo attributes, it is possible to obtain information about the caller to a method. You can obtain file path of the source code, the line number in the source code, and the member name of the caller. CallerInfo attributes instruct the compiler to feed information obtained from the caller's source code into the parameter's default value: This information is helpful for tracing, debugging, and creating diagnostic tools. FIG. 7 demonstrates modified C# example shown in FIG. 5 by using CallerInfo attributes. CallerInfo attributes make metadata access more type safe, metadata access is performed at compile time and it works much faster than processing expression trees at runtime. However, CallerInfo attributes are not a generic solution. Attributes (annotations in Java) are metadata by definition and type safe metadata access using nothing else than another metadata is odd and can't be ideal solution. CallerInfo attributes are suitable for narrow use cases: to safely access member name from inside the member (property or method, but not field), but are not applicable for data querying, because data are contained in fields.
All mentioned downsides can be solved by introducing language improvements to support type safe metadata access which would make compile-time checks possible. For invention disclosure purposes is used ‘Pseudocode A’ which is based on C# programming language feature subset plus new invented features; and ‘Pseudocode B’ which is based on JAVA® programming language feature subset plus new invented features. Type metadata gathering operator “typeof” (Pseudocode A) and “.class” call (Pseudocode B) returns metadata about specified type (class, structure, interface), but there is no type safe way to access class member metadata. For example, programming languages can be extended with operator named ‘memberof’ so that memberof(classField) returns field metadata instance FieldInfo (Pseudocode A) or Field (Pseudocode B) instances instead of field value instances. Microsoft® has been working on design of type safe member metadata access operator named “infoof” (11). The following example shows how non-static field from previous example can be accessed without using instance reference of class:
//Pseudocode A:
FieldInfo instanceMemberMetadata=infoof(Person.FullName);
Alternatively Pseudocode B example would be as follows:
//Pseudocode B:
Field instanceMemberMetadata=infoof(Person.fullName);
Field ‘FullName’ is used like static field, but since type cannot have instance level member and static level member with the same name, there should be no misunderstanding to which field we are pointing to and system should return correct metadata instance. The same is with methods, properties, events and constructors. Microsoft®. has been thinking about operator infoof as similar operator to operator typeof which allows type safe metadata access:
Type info=typeof (int);
Operator typeof accepts parameter which is type instead of instance. Following example is invalid according to C# specification:
Type x=typeof(6);
Use cases of member metadata access operator, that does not accept instance expressions as operator parameter, are too specific and that is not enough for fully type safe member metadata access.